<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>DRAFT: Simple Cloud Identity Management: Protocol 1.0</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta name="description" content="Simple Cloud Identity Management: Protocol 1.0">
    <meta name="keywords" content="SCIM">
    <meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
    <style type='text/css'><!--
    body {
        font-family: verdana, charcoal, helvetica, arial, sans-serif;
        font-size: small; color: #000; background-color: #FFF;
        margin: 2em;
    }
    h1, h2, h3, h4, h5, h6 {
        font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
        font-weight: bold; font-style: normal;
    }
    h1 { color: #900; background-color: transparent; text-align: right; }
    h3 { color: #333; background-color: transparent; }

    td.RFCbug {
        font-size: x-small; text-decoration: none;
        width: 30px; height: 30px; padding-top: 2px;
        text-align: justify; vertical-align: middle;
        background-color: #000;
    }
    td.RFCbug span.RFC {
        font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
        font-weight: bold; color: #666;
    }
    td.RFCbug span.hotText {
        font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
        font-weight: normal; text-align: center; color: #FFF;
    }

    table.TOCbug { width: 30px; height: 15px; }
    td.TOCbug {
        text-align: center; width: 30px; height: 15px;
        color: #FFF; background-color: #900;
    }
    td.TOCbug a {
        font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
        font-weight: bold; font-size: x-small; text-decoration: none;
        color: #FFF; background-color: transparent;
    }

    td.header {
        font-family: arial, helvetica, sans-serif; font-size: x-small;
        vertical-align: top; width: 33%;
        color: #FFF; background-color: #666;
    }
    td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
    td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
    a.info {
        /* This is the key. */
        position: relative;
        z-index: 24;
        text-decoration: none;
    }
    a.info:hover {
        z-index: 25;
        color: #FFF; background-color: #900;
    }
    a.info span { display: none; }
    a.info:hover span.info {
        /* The span will display just on :hover state. */
        display: block;
        position: absolute;
        font-size: smaller;
        top: 2em; left: -5em; width: 15em;
        padding: 2px; border: 1px solid #333;
        color: #900; background-color: #EEE;
        text-align: left;
    }

    a { font-weight: bold; }
    a:link    { color: #900; background-color: transparent; }
    a:visited { color: #633; background-color: transparent; }
    a:active  { color: #633; background-color: transparent; }

    p { margin-left: 2em; margin-right: 2em; }
    p.copyright { font-size: x-small; }
    p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
    table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
    td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

    ol.text { margin-left: 2em; margin-right: 2em; }
    ul.text { margin-left: 2em; margin-right: 2em; }
    li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
    em     { font-style: italic; }
    strong { font-weight: bold; }
    dfn    { font-weight: bold; font-style: normal; }
    cite   { font-weight: normal; font-style: normal; }
    tt     { color: #036; }
    tt, pre, pre dfn, pre em, pre cite, pre span {
        font-family: "Courier New", Courier, monospace; font-size: small;
    }
    pre {
        text-align: left; padding: 4px;
        color: #000; background-color: #CCC;
    }
    pre dfn  { color: #900; }
    pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
    pre .key { color: #33C; font-weight: bold; }
    pre .id  { color: #900; }
    pre .str { color: #000; background-color: #CFF; }
    pre .val { color: #066; }
    pre .rep { color: #909; }
    pre .oth { color: #000; background-color: #FCF; }
    pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
    table.all, table.full, table.headers, table.none {
        font-size: small; text-align: center; border-width: 2px;
        vertical-align: top; border-collapse: collapse;
    }
    table.all, table.full { border-style: solid; border-color: black; }
    table.headers, table.none { border-style: none; }
    th {
        font-weight: bold; border-color: black;
        border-width: 2px 2px 3px 2px;
    }
    table.all th, table.full th { border-style: solid; }
    table.headers th { border-style: none none solid none; }
    table.none th { border-style: none; }
    table.all td {
        border-style: solid; border-color: #333;
        border-width: 1px 2px;
    }
    table.full td, table.headers td, table.none td { border-style: none; }

    hr { height: 1px; }
    hr.insert {
        width: 80%; border-style: none; border-width: 0;
        color: #CCC; background-color: #CCC;
    }
    --></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
    <tr><td class="header">DRAFT</td><td class="header">T. Drake, Ed.</td></tr>
    <tr><td class="header">&nbsp;</td><td class="header">UnboundID</td></tr>
    <tr><td class="header">&nbsp;</td><td class="header">C. Mortimore</td></tr>
    <tr><td class="header">&nbsp;</td><td class="header">SalesForce</td></tr>
    <tr><td class="header">&nbsp;</td><td class="header">M. Ansari</td></tr>
    <tr><td class="header">&nbsp;</td><td class="header">Cisco</td></tr>
    <tr><td class="header">&nbsp;</td><td class="header">K. Grizzle</td></tr>
    <tr><td class="header">&nbsp;</td><td class="header">SailPoint</td></tr>
    <tr><td class="header">&nbsp;</td><td class="header">E. Wahlström</td></tr>
    <tr><td class="header">&nbsp;</td><td class="header">Technology Nexus</td></tr>
    <tr><td class="header">&nbsp;</td><td class="header">December 14, 2011</td></tr>
</table></td></tr></table>
<h1><br />Simple Cloud Identity Management: Protocol 1.0</h1>

<h3>Abstract</h3>

<p>
    The Simple Cloud Identity Management (SCIM) specification is designed to
    make managing user identity in cloud based applications and services
    easier. The specification suite seeks to build upon experience with
    existing schemas and deployments, placing specific emphasis on
    simplicity of development and integration, while applying existing
    authentication, authorization, and privacy models. It's intent is to
    reduce the cost and complexity of user management operations by
    providing a common user schema and extension model, as well as binding
    documents to provide patterns for exchanging this schema using standard
    protocols. In essence, make it fast, cheap, and easy to move users in
    to, out of, and around the cloud.

</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
    <a href="#intro">1.</a>&nbsp;
    Introduction and Overview<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor1">1.1.</a>&nbsp;
    Intended Audience<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#notat">1.2.</a>&nbsp;
    Notational Conventions<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#defs">1.3.</a>&nbsp;
    Definitions<br />
    <a href="#aa">2.</a>&nbsp;
    Authentication and Authorization<br />
    <a href="#api">3.</a>&nbsp;
    API<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#create-resource">3.1.</a>&nbsp;
    Creating Resources<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#get-resources-ops">3.2.</a>&nbsp;
    Retrieving Resources<br />
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#get-resource">3.2.1.</a>&nbsp;
    Retrieving a known Resource<br />
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#query-resources">3.2.2.</a>&nbsp;
    List/Query Resources<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor5">3.3.</a>&nbsp;
    Modifying Resources<br />
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#edit-resource-with-put">3.3.1.</a>&nbsp;
    Modifying with PUT<br />
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#edit-resource-with-patch">3.3.2.</a>&nbsp;
    Modifying with PATCH<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#delete-resource">3.4.</a>&nbsp;
    Deleting Resources<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#bulk-resources">3.5.</a>&nbsp;
    Bulk<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#io-format">3.6.</a>&nbsp;
    Data Input/Output Formats<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#addtl-retrieval-query-params">3.7.</a>&nbsp;
    Additional retrieval query parameters<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#attribute-notation">3.8.</a>&nbsp;
    Attribute Notation<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor6">3.9.</a>&nbsp;
    HTTP Response Codes<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#api-versioning">3.10.</a>&nbsp;
    API Versioning<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#etags">3.11.</a>&nbsp;
    Versioning Resources<br />
    &nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor7">3.12.</a>&nbsp;
    HTTP Method Overloading<br />
    <a href="#Security">4.</a>&nbsp;
    Security Considerations<br />
    <a href="#anchor8">5.</a>&nbsp;
    Contributors<br />
    <a href="#anchor9">6.</a>&nbsp;
    Acknowledgments<br />
    <a href="#rfc.authors">&#167;</a>&nbsp;
    Authors' Addresses<br />
</p>
<br clear="all" />

<a name="intro"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.&nbsp;
    Introduction and Overview</h3>

<p>The SCIM Protocol is an application-level, REST protocol for
    provisioning and managing identity data on the web. The protocol supports creation, modification, retrieval,
    and discovery of core identity Resources; i.e., Users and Groups, as well as custom Resource extensions.

</p>
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.&nbsp;
    Intended Audience</h3>

<p>
    This document is intended as a guide to SCIM API usage for both identity Service Providers and Consumers.

</p>
<a name="notat"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.&nbsp;
    Notational Conventions</h3>

<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].

    These keywords are capitalized when used to unambiguously specify
    requirements of the protocol or application features and behavior that
    affect the interoperability and security of implementations. When
    these words are not capitalized, they are meant in their
    natural-language sense.

</p>
<p>
    For purposes of readability examples are not URL encoded. Implementers
    MUST percent encode URLs as described in
    <a href='http://tools.ietf.org/html/rfc3986#section-2.1'>RFC3896 2.1</a>.

</p>
<a name="defs"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1.3"></a><h3>1.3.&nbsp;
    Definitions</h3>

<blockquote class="text"><dl>
    <dt>Base URL:</dt>
    <dd>The SCIM REST API is always relative to a Base URL. The Base URL MUST NOT contain a
        query string as Consumers may append additional path information and query parameters as part of forming
        the request. Example: https://example.com/scim/v1/

    </dd>
</dl></blockquote>
<a name="aa"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.&nbsp;
    Authentication and Authorization</h3>

<p>
    The SCIM protocol does not define a scheme for authentication and
    authorization therefore implementers are free to choose mechanisms
    appropriate to their use cases. The choice of authentication mechanism
    will impact interoperability. It is RECOMMENDED that clients be
    implemented in such a way that new authentication schemes can be
    deployed. Implementers SHOULD support existing
    authentication/authorization schemes. In particular,
    <a href='http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-14'>OAuth2 Bearer Token</a>
    is RECOMMENDED. Appropriate security considerations of the selected
    authentication and authorization schemes SHOULD be taken.

    Because this protocol uses HTTP response status codes as the primary
    means of reporting the result of a request, servers are advised to
    respond to unauthorized or unauthenticated requests using the 401
    response code in accordance with section 10.4.2 of <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2'>RFC2616</a>.

</p>
<p>
    All examples assume OAuth2 bearer token; e.g.,

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: example.com
Authorization: Bearer h480djs93hd8
</pre></div>
<p>
    The context of the request (i.e. the user for whom data is being
    requested) MUST be inferred by Service Providers.

</p>
<a name="api"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.&nbsp;
    API</h3>

<p>
    The SCIM protocol specifies well known endpoints and HTTP methods for managing Resources defined in the
    core schema; i.e., User and Group Resources correspond to /Users and /Groups respectively.  Service Providers
    that support extended Resources SHOULD define Resource endpoints using the established convention; pluralize
    the Resource name defined in the extended schema by appending an 's'.  Given there are cases where Resource
    pluralization is ambiguous; e.g., a Resource named 'person' is legitimately 'persons' and 'people' Consumers
    SHOULD discover Resource endpoints via the Schema Sub-Attribute 'endpoint'.

</p>
<blockquote class="text"><dl>
    <dt>GET</dt>
    <dd>Retrieves a complete or partial Resource.

    </dd>
    <dt>POST</dt>
    <dd>Create new Resource or bulk modify Resources.

    </dd>
    <dt>PUT</dt>
    <dd>Modifies a Resource with a complete, Consumer
        specified Resource (replace).

    </dd>
    <dt>PATCH</dt>
    <dd>Modifies a Resource with a set of Consumer specified
        changes (partial update).

    </dd>
    <dt>DELETE</dt>
    <dd>Deletes a Resource.

    </dd>
</dl></blockquote><br /><hr class="insert" />
<a name="endpoint-summary"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <col align="left"><col align="left"><col align="left"><col align="left">
    <tr><th align="left">Resource</th><th align="left">Endpoint</th><th align="left">Operations</th><th align="left">Description</th></tr>
    <tr>
        <td align="left">User</td>
        <td align="left">/Users</td>
        <td align="left">
            <a class='info' href='#get-resource'>GET<span> (</span><span class='info'>Retrieving a known Resource</span><span>)</span></a>,
            <a class='info' href='#create-resource'>POST<span> (</span><span class='info'>Creating Resources</span><span>)</span></a>,
            <a class='info' href='#edit-resource-with-put'>PUT<span> (</span><span class='info'>Modifying with PUT</span><span>)</span></a>,
            <a class='info' href='#edit-resource-with-patch'>PATCH<span> (</span><span class='info'>Modifying with PATCH</span><span>)</span></a>,
            <a class='info' href='#delete-resource'>DELETE<span> (</span><span class='info'>Deleting Resources</span><span>)</span></a>
        </td>
        <td align="left">Retrieve/Add/Modify Users</td>
    </tr>
    <tr>
        <td align="left">Group</td>
        <td align="left">/Groups</td>
        <td align="left">
            <a class='info' href='#get-resource'>GET<span> (</span><span class='info'>Retrieving a known Resource</span><span>)</span></a>,
            <a class='info' href='#create-resource'>POST<span> (</span><span class='info'>Creating Resources</span><span>)</span></a>,
            <a class='info' href='#edit-resource-with-put'>PUT<span> (</span><span class='info'>Modifying with PUT</span><span>)</span></a>,
            <a class='info' href='#edit-resource-with-patch'>PATCH<span> (</span><span class='info'>Modifying with PATCH</span><span>)</span></a>,
            <a class='info' href='#delete-resource'>DELETE<span> (</span><span class='info'>Deleting Resources</span><span>)</span></a>
        </td>
        <td align="left">Retrieve/Add/Modify Groups</td>
    </tr>
    <tr>
        <td align="left">Service Provider Configuration</td>
        <td align="left">/ServiceProviderConfigs</td>
        <td align="left">
            <a class='info' href='#get-resource'>GET<span> (</span><span class='info'>Retrieving a known Resource</span><span>)</span></a>
        </td>
        <td align="left">Retrieve the Service Provider's Configuration</td>
    </tr>
    <tr>
        <td align="left">Schema</td>
        <td align="left">/Schemas</td>
        <td align="left">
            <a class='info' href='#get-resource'>GET<span> (</span><span class='info'>Retrieving a known Resource</span><span>)</span></a>
        </td>
        <td align="left">Retrieve a Resource's Schema</td>
    </tr>
    <tr>
        <td align="left">Bulk</td>
        <td align="left">/Bulk</td>
        <td align="left">
            <a class='info' href='#bulk-resources'>POST<span> (</span><span class='info'>Bulk</span><span>)</span></a>
        </td>
        <td align="left">Bulk modify Resources</td>
    </tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 1: Defined endpoints&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>
    All requests to the Service Provider are made via
    <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9'>HTTP operations</a>
    on a URL derived from the Base URL. Responses are returned in the body
    of the HTTP response, formatted as JSON or XML, depending on what is
    requested. Response and error codes SHOULD be transmitted via the HTTP
    status code of the response (if possible), and SHOULD also be specified
    in the body of the response.

</p>
<a name="create-resource"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.&nbsp;
    Creating Resources</h3>

<p>To create new Resources, clients send POST requests to the Resource
    endpoint; i.e., /Users or /Groups.

</p>
<p>Successful Resource creation is indicated with a 201 ("Created")
    response code. Upon successful creation, the response body MUST
    contain the newly created Resource. Since the server is free to alter
    and/or ignore POSTed content, returning the full representation can be
    useful to the client, enabling it to correlate the client and server
    views of the new Resource.

    When a Resource is created, its URI must be returned in the response
    Location header.

</p>
<p>Below, the client sends a POST request containing a User
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST /Users  HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas":["urn:scim:schemas:core:1.0"],
  "userName":"bjensen",
  "externalId":"bjensen",
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  }
}

</pre></div>
<p>The server signals a successful creation with a status code of 201.
    The response includes a Location header indicating the User URI, and a
    representation of that User in the body of the response.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 201 Created
Content-Type: application/json
Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"e180ee84f0671b1"

{
  "schemas":["urn:scim:schemas:core:1.0"],
  "id":"2819c223-7f76-453a-919d-413861904646",
  "externalId":"bjensen",
  "meta":{
    "created":"2011-08-01T21:32:44.882Z",
    "lastModified":"2011-08-01T21:32:44.882Z",
    "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
    "version":"W\/\"e180ee84f0671b1\""
  },
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  },
  "userName":"bjensen"
}
</pre></div>
<a name="get-resources-ops"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.&nbsp;
    Retrieving Resources</h3>

<p>Users and Group Resources are retrieved via opaque, unique URLs or
    via Query. Service Providers MAY choose to respond with a sub-set of
    Resource attributes, though MUST minimally return the Resource id and
    meta attributes.

</p>
<a name="get-resource"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.2.1"></a><h3>3.2.1.&nbsp;
    Retrieving a known Resource</h3>

<p>To retrieve a known Resource, clients send GET requests to the
    Resource endpoint; e.g., /Users/{id} or /Groups/{id}.

</p>
<p>If the Resource exists the server responds with a status code of
    200 and includes the result in the body of the response.

</p>
<p>The below example retrieves a single User via the /Users endpoint.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>


GET /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8

</pre></div>
<p>The server responds with:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>


HTTP/1.1 200 OK
Content-Type: application/json
Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"f250dd84f0671c3"

{
  "schemas":["urn:scim:schemas:core:1.0"],
  "id":"2819c223-7f76-453a-919d-413861904646,
  "externalId":"bjensen",
  "meta":{
    "created":"2011-08-01T18:29:49.793Z",
    "lastModified":"2011-08-01T18:29:49.793Z",
    "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
    "version":"W\/\"f250dd84f0671c3\""
  },
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  },
  "userName":"bjensen",
  "phoneNumbers":[
    {
      "value":"555-555-8377",
      "type":"work"
    }
  ],
  "emails":[
    {
      "value":"bjensen@example.com",
      "type":"work"
    }
  ]
}
</pre></div>
<a name="query-resources"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.2.2"></a><h3>3.2.2.&nbsp;
    List/Query Resources</h3>

<p>
    SCIM defines a standard set of operations that can be used to
    filter, sort, and paginate response results. The operations are
    specified by adding query parameters to the Resource's endpoint.
    Service Providers MAY support additional query parameters not
    specified here, and Providers SHOULD ignore any query parameters
    they don't recognize.

</p>
<p>The below example returns the userName for all Users:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

GET /Users?attributes=userName
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
</pre></div><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 200 OK
Content-Type: application/json

{
  "totalResults":2,
  "schemas":["urn:scim:schemas:core:1.0"],
  "Resources":[
    {
      "userName":"bjensen"
    },
    {
      "userName":"jsmith"
    }
  ]
}</pre></div>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.2.2.1"></a><h3>3.2.2.1.&nbsp;
    Filtering</h3>

<p>
    Filtering is OPTIONAL. Consumers may request a subset of Resources
    by specifying the 'filter' URL query parameter containing a filter
    expression. When specified only those Resources matching the
    filter expression SHALL be returned. The expression language that
    is used in the filter parameter supports references to attributes
    and literals. The literal values can be strings enclosed in double
    quotes, numbers, date times enclosed in double quotes, and Boolean
    values; i.e., true or false.  String literals MUST be valid <a href='http://www.json.org'>JSON strings</a>.

</p>
<p>
    The attribute name and attribute operator are case insensitive.
    For example, the following two expressions will evaluate to the
    same logical value:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
filter=userName Eq "john"

filter=Username eq "john"
</pre></div>
<p>
    The filter parameter MUST contain at least one valid Boolean
    expression. Each expression MUST contain an attribute name
    followed by an attribute operator and optional value. Multiple
    expressions MAY be combined using the two logical operators.
    Furthermore expressions can be grouped together using "()".

</p>
<p>
    The operators supported in the expression are listed in the
    following table.

</p><br /><hr class="insert" />
<a name="filter-operator-table"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <col align="left"><col align="left"><col align="left">
    <tr><th align="left">Operator</th><th align="left">Description</th><th align="left">Behavior</th></tr>
    <tr>
        <td align="left">eq</td>
        <td align="left">equal</td>
        <td align="left">The attribute and operator values must be identical for a
            match.
        </td>
    </tr>
    <tr>
        <td align="left">co</td>
        <td align="left">contains</td>
        <td align="left">The entire operator value must be a substring of the attribute
            value for a match.
        </td>
    </tr>
    <tr>
        <td align="left">sw</td>
        <td align="left">starts with</td>
        <td align="left">The entire operator value must be a substring of the attribute
            value, starting at the beginning of the attribute value. This
            criterion is satisfied if the two strings are identical.
        </td>
    </tr>
    <tr>
        <td align="left">pr</td>
        <td align="left">present (has value)</td>
        <td align="left">If the attribute has a non-empty value, or if it contains a
            non-empty node for complex attributes there is a match.
        </td>
    </tr>
    <tr>
        <td align="left">gt</td>
        <td align="left">greater than</td>
        <td align="left">If the attribute value is greater than operator value, there is
            a match. The actual comparison is dependent on the attribute
            type. For string attribute types, this is a lexicographical
            comparison and for DateTime types, it is a chronological
            comparison.
        </td>
    </tr>
    <tr>
        <td align="left">ge</td>
        <td align="left">greater than or equal</td>
        <td align="left">If the attribute value is greater than or equal to the operator
            value, there is a match. The actual comparison is dependent on
            the attribute type. For string attribute types, this is a
            lexicographical comparison and for DateTime types, it is a
            chronological comparison.
        </td>
    </tr>
    <tr>
        <td align="left">lt</td>
        <td align="left">less than</td>
        <td align="left">If the attribute value is less than operator value, there is a
            match. The actual comparison is dependent on the attribute type.
            For string attribute types, this is a lexicographical comparison
            and for DateTime types, it is a chronological comparison.
        </td>
    </tr>
    <tr>
        <td align="left">le</td>
        <td align="left">less than or equal</td>
        <td align="left">If the attribute value is less than or equal to the operator
            value, there is a match. The actual comparison is dependent on
            the attribute type. For string attribute types, this is a
            lexicographical comparison and for DateTime types, it is a
            chronological comparison.
        </td>
    </tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 2: Attribute
    Operators&nbsp;</b></font><br /></td></tr></table><hr class="insert" />
<br /><hr class="insert" />
<a name="logical-operator-table"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <col align="left"><col align="left"><col align="left">
    <tr><th align="left">Operator</th><th align="left">Description</th><th align="left">Behavior</th></tr>
    <tr>
        <td align="left">and</td>
        <td align="left">Logical And</td>
        <td align="left">The filter is only a match if both expressions evaluate to
            true.
        </td>
    </tr>
    <tr>
        <td align="left">or</td>
        <td align="left">Logical or</td>
        <td align="left">The filter is a match if either expression evaluates to true.
        </td>
    </tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 3: Logical
    Operators&nbsp;</b></font><br /></td></tr></table><hr class="insert" />
<br /><hr class="insert" />
<a name="grouping-operator-table"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <col align="left"><col align="left"><col align="left">
    <tr><th align="left">Operator</th><th align="left">Description</th><th align="left">Behavior</th></tr>
    <tr>
        <td align="left">()</td>
        <td align="left">Precedence grouping</td>
        <td align="left">Boolean expressions may be grouped using parentheses to change
            the standard order of operations; i.e., evaluate OR logical
            operators before logical AND operators.
        </td>
    </tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 4: Grouping
    Operators&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>
    Filters MUST be evaluated using standard
    <a href='http://en.wikipedia.org/wiki/Order_of_operations#Programming_languages'>order of operations</a>.  Attribute operators have the highest precedence,
    followed by the grouping operator (i.e, parentheses), followed by
    the logical AND operator, followed by the logical OR operator.

</p>
<p>
    If the specified attribute in a filter expression is a multi-valued attribute, the Resource MUST match
    if any of the instances of the given attribute match the specified criterion; e.g. if a User has
    multiple emails values, only one has to match for the entire User
    to match. For complex attributes, a fully qualified Sub-Attribute MUST be specified using standard
    <a class='info' href='#attribute-notation'>attribute notation<span> (</span><span class='info'>Attribute Notation</span><span>)</span></a>.  For example, to filter by
    userName the parameter value is userName and to filter by first name, the
    parameter value is name.givenName.

</p>
<p>Providers MAY support additional filter operations if they
    choose. Providers MUST decline to filter results if the specified
    filter operation is not recognized and return a HTTP 400 error
    with an appropriate human readable response. For example, if a
    Consumer specified an unsupported operator named 'regex' the
    Service Provider should specify an error response description
    identifying the Consumer error; e.g., 'The operator 'regex' is not
    supported.'

</p>
<p>
    String type attributes are case insensitive by default unless the
    attribute type is defined as a caseExact string. Attribute
    operators 'eq', 'co', and 'sw' MUST perform caseIgnore matching
    for all string attributes unless the attribute is defined as
    caseExact. By default all string attributes are caseIgnore.

</p>
<p>Examples:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

filter=userName eq "bjensen"

filter=name.familyName co "O'Malley"

filter=userName sw "J"

filter=title pr

filter=meta.lastModified gt "2011-05-13T04:42:34Z"

filter=meta.lastModified ge "2011-05-13T04:42:34Z"

filter=meta.lastModified lt "2011-05-13T04:42:34Z"

filter=meta.lastModified le "2011-05-13T04:42:34Z"

filter=title pr and userType eq "Employee"

filter=title pr or userType eq "Intern"

filter=userType eq "Employee" and (emails co "example.com" or emails
co "example.org")
</pre></div>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.2.2.2"></a><h3>3.2.2.2.&nbsp;
    Sorting</h3>

<p>Sort is OPTIONAL. Sorting allows Consumers to specify the order
    in which Resources are returned by specifying a combination of
    sortBy and sortOrder URL parameters.

</p>
<blockquote class="text"><dl>
    <dt>sortBy:</dt>
    <dd>
        The sortBy parameter specifies the attribute whose value SHALL
        be used to order the returned responses. If the sortBy attribute
        corresponds to a Singular Attribute, Resources are sorted
        according to that attribute's value; if it's a Multi-valued Attribute,
        Resources are sorted by the value of the primary attribute, if
        any, or else the first value in the list, if any. If the
        attribute is complex the attribute name must be a path to a
        Sub-Attribute in standard
        <a class='info' href='#attribute-notation'>attribute notation<span> (</span><span class='info'>Attribute Notation</span><span>)</span></a>
        ; e.g., sortBy=name.givenName. For all attribute
        types, if there is no data for the specified sortBy value they
        are sorted via the 'sortOrder' parameter; i.e., they are ordered
        last if ascending and first if descending.

    </dd>
    <dt>sortOrder:</dt>
    <dd>
        The order in which the sortBy parameter is applied. Allowed
        values are "ascending" and "descending". If a value for sortBy
        is provided and no sortOrder is specified, the sortOrder SHALL
        default to ascending.  String type attributes are case
        insensitive by default unless the attribute type is defined
        as a caseExact string. sortOrder MUST sort according to the
        attribute type; i.e., for caseIgnore attributes, sort the result
        using case insensitive, Unicode alphabetic sort
        order, with no specific locale implied and for caseExact
        attribute types, sort the result using case sensitive,
        Unicode alphabetic sort order.

    </dd>
</dl></blockquote>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.2.2.3"></a><h3>3.2.2.3.&nbsp;
    Pagination</h3>

<p>Pagination parameters can be used together to "page through"
    large numbers of Resources so as not to overwhelm the Consumer or
    Service Provider. Pagination is not session based hence Consumers
    SHOULD never assume repeatable results. For example, a request for
    a list of 10 Resources beginning with a startIndex of 1 may return
    different results when repeated as a Resource in the original
    result could be deleted or new ones could be added in-between
    requests. Pagination parameters and general behavior are derived
    from the
    <a href='http://www.opensearch.org/Specifications/OpenSearch/1.1'>OpenSearch Protocol</a>.

</p>
<p>The following table describes the URL pagination parameters.

</p><br /><hr class="insert" />
<a name="consumer-pagination-options-table"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <col align="left"><col align="left"><col align="left">
    <tr><th align="left">Parameter</th><th align="left">Description</th><th align="left">Default</th></tr>
    <tr>
        <td align="left">startIndex</td>
        <td align="left">The 1-based index of the first search result.
        </td>
        <td align="left">1</td>
    </tr>
    <tr>
        <td align="left">count</td>
        <td align="left">Non-negative Integer. Specifies the desired maximum number of
            search results per page; e.g., 10.
        </td>
        <td align="left">None. When specified the Service Provider MUST not return more
            results than specified though MAY return fewer results. If
            unspecified, the maximum number of results is set by the Service
            Provider.
        </td>
    </tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 5: Pagination Request parameters&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>The following table describes the query response pagination
    attributes specified by the Service Provider.

</p><br /><hr class="insert" />
<a name="response-pagination-options-table"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <col align="left"><col align="left">
    <tr><th align="left">Element</th><th align="left">Description</th></tr>
    <tr>
        <td align="left">itemsPerPage</td>
        <td align="left">Non-negative Integer. Specifies the number of search results
            returned in a query response page; e.g., 10.
        </td>
    </tr>
    <tr>
        <td align="left">totalResults</td>
        <td align="left">Non-negative Integer. Specifies the total number of results
            matching the Consumer query; e.g., 1000.
        </td>
    </tr>
    <tr>
        <td align="left">startIndex</td>
        <td align="left">The 1-based index of the first result in the current set of
            search results; e.g., 1.
        </td>
    </tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 6: Pagination Response Elements&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>
    For example, to retrieve the first 10 Users set the startIndex to
    1 and the count to 10.

</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

GET /Users?startIndex=1&amp;count=10
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
</pre></div><p>


</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
{
  "totalResults":100,
  "itemsPerPage":10,
  "startIndex":1,
  "schemas":["urn:scim:schemas:core:1.0"],
  "Resources":[{
    ...
  }]
}
</pre></div><p>

    Given the example above, to continue paging set the startIndex to
    11 and re-fetch; i.e., /Users?startIndex=11&amp;count=10

</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.3"></a><h3>3.3.&nbsp;
    Modifying Resources</h3>

<p>Resources can be modified in whole or in part via PUT or PATCH,
    respectively. Implementers MUST support PUT as specified in
    <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6'>RFC2616</a>
    . Resources such as Groups may be very large hence implementers SHOULD
    support
    <a href='http://tools.ietf.org/html/rfc5789'>PATCH</a>
    to enable partial resource modifications.

</p>
<a name="edit-resource-with-put"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.3.1"></a><h3>3.3.1.&nbsp;
    Modifying with PUT</h3>

<p>
    PUT performs a full update. Consumers must retrieve the entire
    Resource and PUT the desired modifications as the operation
    overwrites all previously stored data. Unless otherwise specified a
    successful PUT operation returns a 200 OK response code and the
    entire Resource within the response body.

    Example:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PUT /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas":["urn:scim:schemas:core:1.0"],
  "id":"2819c223-7f76-453a-919d-413861904646",
  "userName":"bjensen",
  "externalId":"bjensen",
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara",
    "middleName":"Jane"
  },
  "emails":[
    {
        "value":"bjensen@example.com"
    },
    {
        "value":"babs@jensen.org"
    }
  ]
}


</pre></div>
<p>
    The service responds with the entire, updated User

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 200 OK
Content-Type: application/json
ETag: W/"b431af54f0671a2"
Location:"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646"
{
  "schemas":["urn:scim:schemas:core:1.0"],
  "id":"2819c223-7f76-453a-919d-413861904646",
  "userName":"bjensen",
  "externalId":"bjensen",
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara",
    "middleName":"Jane"
  },
  "emails":[
    {
        "value":"bjensen@example.com"
    },
    {
        "value":"babs@jensen.org"
    }
  ],
  "meta": {
    "created":"2011-08-08T04:56:22Z",
    "lastModified":"2011-08-08T08:00:12Z",
    "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
    "version":"W\/\"b431af54f0671a2\""
  }
}
</pre></div>
<a name="edit-resource-with-patch"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.3.2"></a><h3>3.3.2.&nbsp;
    Modifying with PATCH</h3>

<p>PATCH is OPTIONAL.  PATCH enables consumers to send only those attributes requiring
    modification, reducing network and processing overhead. Attributes
    may be deleted, replaced, merged, or added in a single request.

</p>
<p>The body of a PATCH request MUST contain a partial Resource with
    the desired modifications.  The server MUST return either a 200 OK
    response code and the entire Resource (subject to the "attributes"
    query parameter - see <a class='info' href='#addtl-retrieval-query-params'>Additional Retrieval Query Parameters<span> (</span><span class='info'>Additional retrieval query parameters</span><span>)</span></a>)
    within the response body, or a 204 No Content response code and the
    appropriate response headers for a successful PATCH request.  The
    server MUST return a 200 OK if the "attributes" parameter is
    specified on the request.

</p>
<p>The server MUST process a PATCH request by first removing any
    attributes specified in the meta.attributes Sub-Attribute (if
    present) and then merging the attributes in the PATCH request body
    into the Resource.

</p>
<p>The meta.attributes Sub-Attribute MAY contain a list of attributes
    to be removed from the Resource.  If the PATCH request body contains
    an attribute that is present in the meta.attributes list, the
    attribute on the Resource is replaced with the value from the PATCH
    body.  If the attribute is complex the attribute name must be a path
    to a Sub-Attribute in standard
    <a class='info' href='#attribute-notation'>attribute notation<span> (</span><span class='info'>Attribute Notation</span><span>)</span></a>; e.g., name.givenName.

</p>
<p>Attributes that exist in the PATCH request body but not in the
    meta.attributes Sub-Attribute will be either be updated or added to
    the Resource according to the following rules.

</p>
<blockquote class="text"><dl>
    <dt>Singular attributes:</dt>
    <dd>
        Singular attributes in the PATCH request body replace the
        attribute on the Resource.

    </dd>
    <dt>Complex attributes:</dt>
    <dd>
        Complex Sub-Attribute values in the PATCH request body are merged
        into the complex attribute on the Resource.

    </dd>
    <dt>Multi-valued attributes:</dt>
    <dd>
        An attribute value in the PATCH request body is added to the value collection if the value does not
        exist and merged if a matching value is present. Values are matched by
        comparing the value Sub-Attribute from the PATCH request body to
        the value Sub-Attribute of the Resource.  Attributes that
        do not have a value Sub-Attribute; e.g., addresses, or do not have unique value Sub-Attributes cannot
        be matched and must instead be deleted then added.

        Specific values can be removed from a Resource by adding an "operation" Sub-Attribute with the value
        "delete" to the attribute in the PATCH request body.  As with adding/updating attribute value
        collections, the value to delete is determined by comparing the value Sub-Attribute from the PATCH
        request body to the value Sub-Attribute of the Resource.  Attributes that do not have a value
        Sub-Attribute or that have a non-unique value Sub-Attribute are matched by comparing all Sub-Attribute
        values from the PATCH request body to the Sub-Attribute values of the Resource. A delete operation
        is ignored if the attribute's name is in the meta.attributes list.  If the requested value to
        delete does not match a unique value on the Resource the server MAY return a HTTP 400 error.

    </dd>
</dl></blockquote>
<p>The following example shows how to add a member to a group:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "members": [
    {
      "display": "Babs Jensen",
      "value": "2819c223-7f76-453a-919d-413861904646"
    }
  ]
}
</pre></div>
<p>The "display" Sub-Attribute in this request is optional since the
    value attribute uniquely identifies the user to be added.  If the
    user was already a member of this group, no changes should be made
    to the Resource and a success response should be returned.  The
    server responds with either the entire updated Group or no response
    body:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 204 No Content
Authorization: Bearer h480djs93hd8
ETag: W/"b431af54f0671a2"
Location: "https://example.com/v1/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce"
</pre></div>
<p>The following example shows how to remove a member from a group.
    As with the previous example, the "display" Sub-Attribute is
    optional.  If the user was not a member of this group, no changes
    should be made to the Resource and a success response should be
    returned.

</p>
<p>Note that server responses have been omitted for the rest of the
    PATCH examples.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "members": [
    {
      "display": "Babs Jensen",
      "value": "2819c223-7f76-453a-919d-413861904646"
      "operation": "delete"
    }
  ]
}
</pre></div>
<p>The following example shows how to remove all members from a
    group:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "meta": {
    "attributes": [
      "members"
    ]
  }
}
</pre></div>
<p>The following example shows how to replace all of the members of a
    group with a different members list:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "meta": {
    "attributes": [
      "members"
    ]
  },
  "members": [
    {
      "display": "Babs Jensen",
      "value": "2819c223-7f76-453a-919d-413861904646"
    },
    {
      "display": "James Smith",
      "value": "08e1d05d-121c-4561-8b96-473d93df9210"
    }
  ]
}
</pre></div>
<p>The following example shows how to add a member to and remove a
    member from a Group in a single request:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "members": [
    {
      "display": "Babs Jensen",
      "value": "2819c223-7f76-453a-919d-413861904646"
      "operation": "delete"
    },
    {
      "display": "James Smith",
      "value": "08e1d05d-121c-4561-8b96-473d93df9210"
    }
  ]
}
</pre></div>
<p>The following example shows how to change a User's primary email.
    If the User already has the email address, it is made the primary
    address and the current primary address (if present) is made
    non-primary.  If the User does not already have the email address,
    it is added and made the primary address.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: "a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "emails": [
    {
      "value": "bjensen@example.com",
      "primary": true
    }
  ]
}
</pre></div>
<p>The following example shows how to change a User's address.  Since
    address does not have a value Sub-Attribute, the existing address
    must be removed and the modified address added.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "addresses": [
    {
      "type": "work",
      "streetAddress": "100 Universal City Plaza",
      "locality": "Hollywood",
      "region": "CA",
      "postalCode": "91608",
      "country": "US",
      "formatted": "100 Universal City Plaza\nHollywood, CA 91608 US",
      "primary": true
      "operation": "delete"
    },
    {
      "type": "work",
      "streetAddress": "911 Universal City Plaza",
      "locality": "Hollywood",
      "region": "CA",
      "postalCode": "91608",
      "country": "US",
      "formatted": "911 Universal City Plaza\nHollywood, CA 91608 US",
      "primary": true
    }
  ]
}
</pre></div>
<p>The following example shows how to change a User's nickname:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "nickName": "Barbie"
}
</pre></div>
<p>The following example shows how to remove a User's nickname:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "meta": {
    "attributes": [
      "nickName"
    ]
  }
}
</pre></div>
<p>The following example shows how to change a User's familyName.
    This only updates the familyName and formatted on the "name" complex
    attribute. Any other name Sub-Attributes on the Resource remain
    unchanged.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "name": {
    "formatted": "Ms. Barbara J Jensen III",
    "familyName": "Jensen"
  }
}
</pre></div>
<p>The following example shows how to remove a complex Sub-Attribute
    and an extended schema attribute from a User.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
PATCH /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
ETag: W/"a330bc54f0671c9"

{
  "schemas": ["urn:scim:schemas:core:1.0"],
  "meta": {
    "attributes": [
      "name.formatted",
      "urn:hr:schemas:user:age"
    ]
  }
}
</pre></div>
<a name="delete-resource"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.4"></a><h3>3.4.&nbsp;
    Deleting Resources</h3>

<p>Consumers request Resource removal via DELETE. Service Providers MAY
    choose not to permanently delete the Resource, but MUST return a 404
    error code for all operations associated with the previously deleted
    Id. Service Providers MUST also omit the Resource from future query
    results.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>


DELETE /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Authorization: Bearer h480djs93hd8
ETag: W/"c310cd84f0281b7"

</pre></div><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 200 OK
</pre></div>
<p>Example: Consumer attempt to retrieve the previously deleted User
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>


GET /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Authorization: Bearer h480djs93hd8
</pre></div><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 404 NOT FOUND

{
  "Errors":[
    {
      "description":"Resource 2819c223-7f76-453a-919d-413861904646 not found",
      "code":"404"
    }
  ]
}

</pre></div>
<a name="bulk-resources"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.5"></a><h3>3.5.&nbsp;
    Bulk</h3>

<p>
    Bulk is OPTIONAL. The bulk operation enables Consumers to send a potentially large collection of
    Resource operations in a single request.  The body of a a bulk operation contains a set of HTTP
    Resource operations using one of the API supported HTTP methods; i.e., POST, PUT, PATCH or DELETE.

</p>
<p>
    The following Singular Attribute is defined in addition to the
    common attributes defined in SCIM core schema.

</p>
<p>
</p>
<blockquote class="text"><dl>
    <dt>failOnErrors</dt>
    <dd>
        An Integer specifying the number of errors that the Service Provider will accept before the
        operation is terminated and an error response is returned. OPTIONAL.

    </dd>
</dl></blockquote><p>

</p>
<p>
    The following Complex Multi-valued Attribute is defined in addition to
    the common attributes defined in core schema.

</p>
<p>
</p>
<blockquote class="text"><dl>
    <dt>Operations</dt>
    <dd>
        Defines operations within a bulk job. Each operation corresponds to a single HTTP request against a Resource
        endpoint. REQUIRED.

        <blockquote class="text"><dl>
            <dt>method</dt>
            <dd>
                The HTTP method of the current operation. Possible values are POST, PUT, PATCH or DELETE. REQUIRED.

            </dd>
            <dt>bulkId</dt>
            <dd>
                The transient identifier of a newly created Resource, unique within a bulk request and created by
                the Consumer. The bulkId serves as a surrogate Resource id enabling Consumers to uniquely
                identify newly created Resources in the Response and cross reference new Resources in and
                across operations within a bulk request.  REQUIRED when method is POST.

            </dd>
            <dt>version</dt>
            <dd>
                The current Resource version. Version is REQUIRED if the Service Provider supports ETags and the
                method is PUT, DELETE, or PATCH.

            </dd>
            <dt>path</dt>
            <dd>
                The Resource's relative path.  If the method is POST the value must specify a Resource type
                endpoint; e.g., /Users or /Groups whereas all other method values must specify the path to
                a specific Resource; e.g., /Users/2819c223-7f76-453a-919d-413861904646.  REQUIRED in a request.

            </dd>
            <dt>data</dt>
            <dd>
                The Resource data as it would appear for a single POST, PUT or PATCH Resource operation.
                REQUIRED in a request when method is POST, PUT and PATCH.

            </dd>
            <dt>location</dt>
            <dd>
                The Resource endpoint URL. REQUIRED in a response, except in the event of a POST failure.

            </dd>
            <dt>status</dt>
            <dd>
                A complex type that contains information about the
                success or failure of one operation within the bulk job.
                REQUIRED in a response.

            </dd>
            <blockquote class="text"><dl>
                <dt>code</dt>
                <dd>
                    The HTTP response code that would have been
                    returned if a a single HTTP request would have been
                    used. REQUIRED.

                </dd>
                <dt>description</dt>
                <dd>
                    A human readable error message. REQUIRED when an error
                    occurred.

                </dd>
            </dl></blockquote>
        </dl></blockquote>

    </dd>
</dl></blockquote><p>

</p>
<p>
    If a bulk job is processed successfully the HTTP response code
    200 OK MUST be returned, otherwise an appropriate HTTP error code
    MUST be returned.

</p>
<p>
    The Service Provider MUST continue performing as many changes as
    possible and disregard partial failures. The Consumer MAY override
    this behavior by specifying a value for failOnErrors attribute. The failOnErrors
    attribute defines the number of errors that the Service Provider
    should accept before failing the remaining operations returning the
    response.

</p>
<p>
    To be able to reference a newly created Resource the attribute
    bulkId MUST be specified when creating new Resources. The bulkId is
    defined by the Consumer as a surrogate identifier in a POST operation.
    The Service Provider MUST return the same bulkId together with
    the newly created Resource. The bulkId can then be used by the
    Consumer to map the Service Provider id with the
    bulkId of the created Resource.

</p>
<p>
    There can be more then one operation per Resource in each
    bulk job. The Service Consumer MUST take notice of the unordered
    structure of JSON and the Service Provider can process operations in any order.
    For example, if the Service Consumer sends two PUT operations in one request, the outcome
    is non-deterministic.

</p>
<p>
    The Service Provider response MUST include the result of all processed operations. A location attribute
    that includes the Resource's end point MUST be returned for all operations excluding failed
    POSTs. The status attribute includes information about the success or failure of one operation within
    the bulk job.  The attribute status MUST include the code attribute that holds the HTTP response code
    that would have been returned if a single HTTP request would have been used. If an error occurred
    the status MUST also include the description attribute containing a human readable explanation of the
    error.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

"status": {
  "code": "201"
}
</pre></div>
<p>
    The following is an example of a status in a failed operation.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

"status": {
  "code": "400",
  "description": "Request is unparseable, syntactically incorrect, or violates schema."
}</pre></div>
<p>
    The following example shows how to add, update, and remove a user. The failOnErrors
    attribute is set to '1' indicating the Service Provider should return
    on the first error. The POST operation's bulkId value is set to 'qwerty' enabling the Consumer to match
    the new User with the returned Resource id '92b725cd-9465-4e7d-8c16-01f8e146b87a'.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

POST /v1/Bulk
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas":[
    "urn:scim:schemas:core:1.0"
  ],
  "failOnErrors":1,
  "Operations":[
    {
      "method":"POST",
      "path":"/Users",
      "bulkId":"qwerty",
      "data":{
        "schemas":[
          "urn:scim:schemas:core:1.0"
        ],
        "userName":"Alice"
      }
    },
    {
      "method":"PUT",
      "path":"/Users/b7c14771-226c-4d05-8860-134711653041",
      "version":"W\/\"3694e05e9dff591\"",
      "data":{
        "schemas":[
          "urn:scim:schemas:core:1.0"
        ],
        "id":"b7c14771-226c-4d05-8860-134711653041",
        "userName":"Bob"
      }
    },
    {
      "method":"PATCH",
      "path":"/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
      "version":"W\/\"edac3253e2c0ef2\"",
      "data":{
        "schemas":[
          "urn:scim:schemas:core:1.0"
        ],
        "id":"5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
        "userName":"Dave",
        "meta":{
          "attributes":[
            "nickName"
          ]
        }
      }
    },
    {
      "method":"DELETE",
      "path":"/Users/e9025315-6bea-44e1-899c-1e07454e468b",
      "version":"W\/\"0ee8add0a938e1a\""
    }
  ]
}</pre></div>
<p>
    The Service Provider returns the following response.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 200 OK
Content-Type: application/json

{
    "schemas": [
        "urn:scim:schemas:core:1.0"
    ],
    "Operations": [
        {
            "location": "https://example.com/v1/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a",
            "method": "POST",
            "bulkId": "qwerty",
            "version": "W\/\"oY4m4wn58tkVjJxK\"",
            "status": {
                "code": "201"
            }
        },
        {
            "location": "https://example.com/v1/Users/b7c14771-226c-4d05-8860-134711653041",
            "method": "PUT",
            "version": "W\/\"huJj29dMNgu3WXPD\"",
            "status": {
                "code": "200"
            }
        },
        {
            "location": "https://example.com/v1/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
            "method": "PATCH",
            "version": "W\/\"huJj29dMNgu3WXPD\"",
            "status": {
                "code": "200"
            }
        },
        {
            "location": "https://example.com/v1/Users/e9025315-6bea-44e1-899c-1e07454e468b",
            "method": "DELETE",
            "status": {
                "code": "200"
            }
        }
    ]
}</pre></div>
<p>
    The following response is returned if an error occurred when attempting to create the User 'Alice'. The
    Service Provider stops processing the bulk operation and immediately returns a response to the Consumer.
    The response contains the error and any successful results prior to the error.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 200 OK
Content-Type: application/json

{
  "schemas": [
    "urn:scim:schemas:core:1.0"
  ],
  "Operations": [
    {
      "method": "POST",
      "bulkId": "qwerty",
      "status": {
        "code": "400",
        "description": "Request is unparseable, syntactically incorrect, or violates schema."
      }
    }
  ]
}</pre></div>
<p>
    If the failOnErrors attribute is not specified or the Service Provider has
    not reached the error limit defined by the Consumer the Service Provider
    will continue to process all operations. The following is an example
    in which all operations failed.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 200 OK
Content-Type: application/json

{
  "schemas": [
    "urn:scim:schemas:core:1.0"
  ],
  "Operations": [
    {
      "method": "POST",
      "bulkId": "qwerty",
      "status": {
        "code": "400",
        "description": "Request is unparseable, syntactically incorrect, or violates schema."
      }
    },
    {
      "location": "https://example.com/v1/Users/b7c14771-226c-4d05-8860-134711653041",
      "method": "PUT",
      "status": {
        "code": "412",
        "description": "Failed to update as user changed on the server since you last retrieved it."
      }
    },
    {
      "location": "https://example.com/v1/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
      "method": "PATCH",
      "status": {
        "code": "412",
        "description": "Failed to update as user changed on the server since you last retrieved it."
      }
    },
    {
      "location": "https://example.com/v1/Users/e9025315-6bea-44e1-899c-1e07454e468b",
      "method": "DELETE",
      "status": {
        "code": "404",
        "description": "Specified resource; e.g., User, does not exist."
      }
    }
  ]
}</pre></div>
<p>
    The Consumer can, within one bulk operation, create a new User, a new Group and add the newly created User to
    the newly created Group.  In order to add the new User to the Group
    the Consumer must use the surrogate id attribute, bulkId, to reference the User. The bulkId attribute value
    must be pre-pended with the literal "bulkId:"; e.g., if the bulkId is 'qwerty' the value is  “bulkId:qwerty”.
    The Service Provider MUST replace the string “bulkId:qwerty” with the permanent Resource id once created.

</p>
<p>
    The following example creates a User with the userName 'Alice' and a Group
    with the displayName 'Tour Guides' with Alice as a member.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

POST /v1/Bulk
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas": [
    "urn:scim:schemas:core:1.0"
  ],
  "Operations": [
    {
      "method": "POST",
      "path": "/Users",
      "bulkId": "qwerty",
      "data": {
        "schemas": [
          "urn:scim:schemas:core:1.0"
        ],
        "userName": "Alice"
      }
    },
    {
      "method": "POST",
      "path": "/Groups",
      "bulkId": "ytrewq",
      "data": {
        "schemas": [
          "urn:scim:schemas:core:1.0"
        ],
        "displayName": "Tour Guides",
        "members": [
          {
            "type": "user",
            "value": "bulkId:qwerty"
          }
        ]
      }
    }
  ]
}</pre></div>
<p>
    The Service Provider returns the following response.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 200 OK
Content-Type: application/json

{
  "schemas": [
    "urn:scim:schemas:core:1.0"
  ],
  "Operations": [
    {
      "location": "https://example.com/v1/Users/92b725cd-9465-4e7d-8c16-01f8e146b87a",
      "method": "POST",
      "bulkId": "qwerty",
      "version": "W\/\"4weymrEsh5O6cAEK\"",
      "status": {
        "code": "201"
      }
    },
    {
      "location": "https://example.com/v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
      "method": "POST",
      "bulkId": "ytrewq",
      "version": "W\/\"lha5bbazU3fNvfe5\"",
      "status": {
        "code": "201"
      }
    }
  ]
}</pre></div>
<p>
    A subsequent request for the 'Tour Guides' Group ('e9e30dba-f08f-4109-8486-d5c6a331660a') returns the following:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

GET /v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
</pre></div><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 200 OK
Content-Type: application/json
Location: https://example.com/v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a
ETag: W/"lha5bbazU3fNvfe5"

{
  "schemas":["urn:scim:schemas:core:1.0"],
  "id": "e9e30dba-f08f-4109-8486-d5c6a331660a",
  "displayName": "Tour Guides",
  "meta": {
    "created":"2011-08-01T18:29:49.793Z",
    "lastModified":"2011-08-01T20:31:02.315Z",
    "location": "https://example.com/v1/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a",
    "version": "W\/\"lha5bbazU3fNvfe5\""
  },
  "members": [
    {
      "value": "92b725cd-9465-4e7d-8c16-01f8e146b87a",
      "type": "user"
    }
  ]
}</pre></div>
<p>
    Extensions that include references to other Resources MUST be handled in the same way by the Service
    Provider. The following example uses the bulkId attribute within the enterprise extension managerId attribute.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

POST /v1/Bulk
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas": [
    "urn:scim:schemas:core:1.0"
  ],
  "Operations": [
    {
      "method": "POST",
      "path": "/Users",
      "bulkId": "qwerty",
      "data": {
        "schemas": [
          "urn:scim:schemas:core:1.0"
        ],
        "userName": "Alice"
      }
    },
    {
      "method": "POST",
      "path": "/Users",
      "bulkId": "ytrewq",
      "data": {
        "schemas": [
          "urn:scim:schemas:core:1.0",
          "urn:scim:schemas:extension:enterprise:1.0"
        ],
        "userName": "Bob",
        "urn:scim:schemas:extension:enterprise:1.0": {
          "employeeNumber": "11250",
          "manager": {
            "managerId": "batchId:qwerty",
            "displayName": "Alice"
          }
        }
      }
    }
  ]
}</pre></div>
<p>
    The Service Provider MUST try to resolve circular cross references
    between Resources in a single bulk job but MAY stop after a failed
    attempt and instead return the status code 409 Conflict. The following
    example exhibits the potential conflict.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

POST /v1/Bulk
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas": [
    "urn:scim:schemas:core:1.0"
  ],
  "Operations": [
    {
      "method": "POST",
      "path": "/Groups",
      "bulkId": "qwerty",
      "data": {
        "schemas": [
          "urn:scim:schemas:core:1.0"
        ],
        "displayName": "Group A",
        "members": [
          {
            "type": "group",
            "value": "bulkId:ytrewq"
          }
        ]
      }
    },
    {
      "method": "POST",
      "path": "/Groups",
      "bulkId": "ytrewq",
      "data": {
        "schemas": [
          "urn:scim:schemas:core:1.0"
        ],
        "displayName": "Group B",
        "members": [
          {
            "type": "group",
            "value": "bulkId:qwerty"
          }
        ]
      }
    }
  ]
}</pre></div>
<p>
    If the Service Provider resolved the above circular references the following is returned from a subsequent
    GET request.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

GET /v1/Groups?filter=displayName sw 'Group'
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
</pre></div><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 200 OK
Content-Type: application/json

{
  "totalResults": 2,
  "schemas": [
    "urn:scim:schemas:core:1.0"
  ],
  "Resources": [
    {
      "id": "c3a26dd3-27a0-4dec-a2ac-ce211e105f97",
      "schemas": [
        "urn:scim:schemas:core:1.0"
      ],
      "displayName": "Group A",
      "meta": {
        "created":"2011-08-01T18:29:49.793Z",
        "lastModified":"2011-08-01T18:29:51.135Z",
        "location":"https://example.com/v1/Groups/c3a26dd3-27a0-4dec-a2ac-ce211e105f97",
        "version":"W\/\"mvwNGaxB5SDq074p\""
      },
      "members": [
        {
          "value": "6c5bb468-14b2-4183-baf2-06d523e03bd3",
          "type": "group"
        }
      ]
    },
    {
      "id": "6c5bb468-14b2-4183-baf2-06d523e03bd3",
      "schemas": [
        "urn:scim:schemas:core:1.0"
      ],
      "displayName": "Group B",
      "meta": {
        "created":"2011-08-01T18:29:50.873Z",
        "lastModified":"2011-08-01T18:29:50.873Z",
        "location":"https://example.com/v1/Groups/6c5bb468-14b2-4183-baf2-06d523e03bd3",
        "version":"W\/\"wGB85s2QJMjiNnuI\""
      },
      "members": [
        {
          "value": "c3a26dd3-27a0-4dec-a2ac-ce211e105f97",
          "type": "group"
        }
      ]
    }
  ]
}</pre></div>
<p>
    The Service Provider MUST define a limit on how many operations
    can be sent in one bulk request. The Service Provider MUST also define the
    max payload size of a bulk request. If either limits are exceeded the Service Provider
    MUST return the HTTP response code 413 Request Entity Too Large. The
    returned response must also include the attributes maxOperations and
    maxPayloadSize with the limits accepted by the Service Provider.

</p>
<p>
    In the following example the Consumer sent a request that exceeded the Service Provider's max  payload size
    1 megabyte.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

POST /v1/Bulk
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
Content-Length: 4294967296

…</pre></div><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 413 Request Entity Too Large
Content-Type: application/json
Location: https://example.com/v1/Bulk/yfCrVJhFIJagAHj8

{
  "maxOperations": 1000,
  "maxPayload": 1048576
}</pre></div>
<a name="io-format"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.6"></a><h3>3.6.&nbsp;
    Data Input/Output Formats</h3>

<p>
    Consumers MUST specify the format in which the data is submitted via the
    <a href='http://tools.ietf.org/html/rfc2616#section-14.17 '>HTTP header content-type</a> and
    MAY specify the desired response data format via an HTTP Accept Header; e.g.,"Accept:
    application/json" or via URI suffix; e.g.,

</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

GET /Users/2819c223-7f76-453a-919d-413861904646.json
Host: example.com

GET /Users/2819c223-7f76-453a-919d-413861904646.xml
Host: example.com
</pre></div><p>



</p>
<p>
    Service Providers MUST support the Accept Headers "Accept:
    application/json" for <a href='http://json.org'>JSON</a>
    and, if supported, "Accept: application/xml" for
    <a href='http://www.w3.org/XML/'>XML</a>. The format defaults to
    JSON if no format is specified. The data structure returned is
    equivalent in both formats; the only difference is in the encoding of
    the data.

</p>
<p>
    Singular attributes are encoded as string name-value-pairs in JSON;
    e.g.,

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
"attribute": "value"
</pre></div>
<p>and elements in XML; e.g.,
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
&lt;attribute&gt;value&lt;/attribute&gt;
</pre></div>
<p>
    Multi-valued attributes in JSON are encoded as arrays; e.g.,

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
"attributes": [ "value1", "value2" ]
</pre></div>
<p>
    and repeated tags in XML; e.g.,

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
&lt;attributes&gt;value1&lt;/attributes&gt;
&lt;attributes&gt;value2&lt;/attributes&gt;
</pre></div>
<p>
    Elements with nested elements are represented as objects in JSON; e.g,

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
"attribute": { "subattribute1": "value1", "subattribute2": "value2" }
</pre></div>
<p>
    and repeated tags in XML; e.g.,

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
&lt;attribute&gt;
  &lt;subattribute1&gt;value1&lt;/subattribute1&gt;
  &lt;subattribute2&gt;value2&lt;/subattribute2&gt;
&lt;/attribute&gt;
</pre></div>
<a name="addtl-retrieval-query-params"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.7"></a><h3>3.7.&nbsp;
    Additional retrieval query parameters</h3>

<p>
    Consumers MAY request a partial Resource representation on any
    operation that returns a Resource within the response by specifying
    the URL query parameter 'attributes'. When specified, each Resource
    returned MUST contain the minimal set of Resource attributes and, MUST
    contain no other attributes or Sub-Attributes than those explicitly requested.

    The query parameter attributes value is a comma separated list of
    Resource attribute names in standard,
    <a class='info' href='#attribute-notation'>attribute notation<span> (</span><span class='info'>Attribute Notation</span><span>)</span></a> form (e.g. userName, name, emails).

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8

</pre></div>
<p>Giving the response
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 200 OK
Content-Type: application/json
Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"a330bc54f0671c9"

{
  "schemas":["urn:scim:schemas:core:1.0"],
  "id":"2819c223-7f76-453a-919d-413861904646",
  "userName":"bjensen",
  "meta":{
    "created":"2011-08-01T18:29:49.793Z",
    "lastModified":"2011-08-01T18:29:49.793Z",
    "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
    "version":"W\/\"a330bc54f0671c9\""
  }
}

</pre></div>
<a name="attribute-notation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.8"></a><h3>3.8.&nbsp;
    Attribute Notation</h3>

<p>
    All operations share a common scheme for referencing simple and complex  attributes.  In general, attributes
    are identified by prefixing the attribute name with its schema URN
    separated by a ':' character; e.g., the core User Resource attribute 'userName' is identified as
    'urn:scim:schemas:core:1.0:userName'.  Consumers MAY omit core schema attribute URN prefixes though MUST fully
    qualify extended attributes with the associated Resource URN; e.g., the attribute 'age' defined in
    'urn:hr:schemas:user' is fully encoded as 'urn:hr:schemas:user:age'.

    A Complex attributes' Sub-Attributes are referenced via nested, dot ('.') notation;
    i.e., {urn}:{Attribute name}.{Sub-Attribute name}.  For example, the fully qualified path for a User's
    givenName is urn:scim:schemas:core:1.0:name.givenName

    All facets (URN, attribute and Sub-Attribute name) of the fully encoded Attribute name are case insensitive.

</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.9"></a><h3>3.9.&nbsp;
    HTTP Response Codes</h3>

<p>
    The SCIM Protocol uses the response
    <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html'>status codes defined in HTTP</a>
    to indicate operation success or failure. In addition to returning a
    HTTP response code implementers MUST return the errors in the body of
    the response in the client requested format containing the error
    response and, per the HTTP specification, human-readable explanations.
    Implementers SHOULD handle the identified errors as described below.

</p><br /><hr class="insert" />
<a name="http-error-handling-table"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
    <col align="left"><col align="left"><col align="left">
    <tr><th align="left">Code</th><th align="left">Applicability</th><th align="left">Suggested Explanation</th></tr>
    <tr>
        <td align="left">400 BAD REQUEST</td>
        <td align="left">GET,POST,PUT,PATCH,DELETE</td>
        <td align="left">Request is unparseable, syntactically incorrect, or violates schema
        </td>
    </tr>
    <tr>
        <td align="left">401 UNAUTHORIZED</td>
        <td align="left">GET,POST,PUT,PATCH,DELETE</td>
        <td align="left">Authorization failure</td>
    </tr>
    <tr>
        <td align="left">403 FORBIDDEN</td>
        <td align="left">GET,POST,PUT,PATCH,DELETE</td>
        <td align="left">Server does not support requested operation</td>
    </tr>
    <tr>
        <td align="left">404 NOT FOUND</td>
        <td align="left">GET,PUT,PATCH,DELETE</td>
        <td align="left">Specified resource; e.g., User, does not exist</td>
    </tr>
    <tr>
        <td align="left">409 CONFLICT</td>
        <td align="left">PUT,PATCH,DELETE</td>
        <td align="left">The specified version number does not match the resource's latest
            version number or a Service Provider refused to create a new,
            duplicate resource
        </td>
    </tr>
    <tr>
        <td align="left">412 PRECONDITION FAILED</td>
        <td align="left">PUT,PATCH,DELETE</td>
        <td align="left">Failed to update as Resource {id} changed on the server last retrieved
        </td>
    </tr>
    <tr>
        <td align="left">413 REQUEST ENTITY TOO LARGE</td>
        <td align="left">POST</td>
        <td align="left">{"maxOperations": 1000,"maxPayload": 1048576}</td>
    </tr>
    <tr>
        <td align="left">500 INTERNAL SERVER ERROR</td>
        <td align="left">GET,POST,PUT,PATCH,DELETE</td>
        <td align="left">An internal error. Implementers SHOULD provide descriptive
            debugging advice
        </td>
    </tr>
    <tr>
        <td align="left">501 NOT IMPLEMENTED</td>
        <td align="left">GET,POST,PUT,PATCH,DELETE</td>
        <td align="left">Service Provider does not support the request operation; e.g.,
            PATCH
        </td>
    </tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 7: Defined error cases&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>Error example in response to a non-existent GET request.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 404 NOT FOUND

{
  "Errors":[
    {
      "description":"Resource 2819c223-7f76-453a-919d-413861904646 not found",
      "code":"404"
    }
  ]
}
</pre></div>
<a name="api-versioning"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.10"></a><h3>3.10.&nbsp;
    API Versioning</h3>

<p>
    The Base URL MAY be appended with a version identifier as a separate segment in the URL path.  At this time the
    only valid identifier is 'v1'.  If specified, the version identifier MUST appear in the URL path immediately
    preceding the Resource endpoint and conform to the following scheme: the character 'v' followed by the desired
    SCIM version number; e.g., a version 'v1' User request is specified as /v1/Users.  When specified Service
    Providers MUST perform the operation using the desired version or reject the request.  When omitted Service
    Providers SHOULD perform the operation using the most recent API supported by the Service Provider.

</p>
<a name="etags"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.11"></a><h3>3.11.&nbsp;
    Versioning Resources</h3>

<p>
    The API supports resource versioning via standard,<a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19'>HTTP ETags</a>. Service providers MAY support weak ETags as the preferred mechanism for performing
    conditional retrievals and ensuring Consumers do not inadvertently overwrite each others
    changes, respectively. When supported SCIM ETags MUST be specified as an HTTP header and SHOULD be
    specified within the 'version' attribute contained in the Resource's 'meta' attribute.

</p>
<p>Example:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST /Users  HTTP/1.1
Host: example.com
Content-Type:  application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas":["urn:scim:schemas:core:1.0"],
  "userName":"bjensen",
  "externalId":"bjensen",
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  }
}
</pre></div>
<p>The server responds with an ETag in the response header and meta
    structure.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 201 Created
Content-Type: application/json
Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"e180ee84f0671b1"

{
  "schemas":["urn:scim:schemas:core:1.0"],
  "id":"2819c223-7f76-453a-919d-413861904646",
  "meta":{
    "created":"2011-08-01T21:32:44.882Z",
    "lastModified":"2011-08-01T21:32:44.882Z",
    "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
    "version":"W\/\"e180ee84f0671b1\""
  },
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  },
  "userName":"bjensen"
}
</pre></div>
<p>With the returned ETag, Consumers MAY choose to retrieve the Resource
    only if the Resource has been modified. In addition, if updating,
    specifying an ETag guarantees that previous updates will not be
    overwritten.

</p>
<p>Conditional retrieval example using
    <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26'>If-None-Match</a>
    header:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=displayName
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
If-None-Match: W/"e180ee84f0671b1"

</pre></div>
<p>
    If the Resource has not changed the Service Provider simply returns an
    empty body with a 304 "Not Modified" response code.

</p>
<p>
    Similarly, consumers MAY supply an
    <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24'>If-Match</a>
    ETag header for PUT, PATCH, and DELETE operations to ensure that the
    requested operation succeeds only if the supplied ETag matches the
    latest Service Provider Resource; e.g., If-Match: W/"e180ee84f0671b1"

</p>
<p>
    To perform DELETE, PATCH, or PUT operations and override ETag
    versioning specify
    <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24'>"If-Match: *"</a>
    in lieu of an ETag header.

</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.12"></a><h3>3.12.&nbsp;
    HTTP Method Overloading</h3>

<p>In recognition that some clients, servers and firewalls prevent PUT,
    PATCH and DELETE operations a client MAY override the POST operation
    by specifying the custom header "X-HTTP-Method-Override" with the
    desired PUT, PATCH, DELETE operation. For example:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

POST /Users/2819c223-7f76-453a-919d-413861904646
X-HTTP-Method-Override: DELETE
</pre></div>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.&nbsp;
    Security Considerations</h3>

<p>
    The SCIM Protocol is based on HTTP and thus subject to the security considerations found in Section 15 of
    <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15'>[RFC2616]</a>.
    SCIM Resources (e.g., Users and Groups) can contain sensitive information.  Therefore, SCIM Consumers and
    Service Providers MUST implement TLS.  Which version(s) ought to be implemented will vary over time, and depend on the
    widespread deployment and known security vulnerabilities at the time of implementation.  At the time of this
    writing, TLS version 1.2 [<a href='http://tools.ietf.org/html/rfc5246'>RFC5246</a>] is the most
    recent version, but has very limited actual deployment, and might not be readily available in
    implementation toolkits.  TLS version 1.0 [<a href='http://tools.ietf.org/html/rfc5246'>RFC2246</a>]
    is the most widely deployed version, and will give the broadest interoperability.

</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.&nbsp;
    Contributors</h3>

<p>
</p>
<blockquote class="text">
    <p>Samuel Erdtman (samuel@erdtman.se)
    </p>
    <p>Patrick Harding (pharding@pingidentity.com)
    </p>
</blockquote><p>

</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.&nbsp;
    Acknowledgments</h3>

<p>The editor would like to thank the participants in the the SCIM working group for their support of this specification.
</p>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
    <tr><td class="author-text">&nbsp;</td>
        <td class="author-text">Trey Drake (editor)</td></tr>
    <tr><td class="author-text">&nbsp;</td>
        <td class="author-text">UnboundID</td></tr>
    <tr><td class="author" align="right">Email:&nbsp;</td>
        <td class="author-text"><a href="mailto:trey.drake@unboundid.com">trey.drake@unboundid.com</a></td></tr>
    <tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
    <tr><td class="author-text">&nbsp;</td>
        <td class="author-text">Chuck Mortimore</td></tr>
    <tr><td class="author-text">&nbsp;</td>
        <td class="author-text">SalesForce</td></tr>
    <tr><td class="author" align="right">Email:&nbsp;</td>
        <td class="author-text"><a href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a></td></tr>
    <tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
    <tr><td class="author-text">&nbsp;</td>
        <td class="author-text">Morteza Ansari</td></tr>
    <tr><td class="author-text">&nbsp;</td>
        <td class="author-text">Cisco</td></tr>
    <tr><td class="author" align="right">Email:&nbsp;</td>
        <td class="author-text"><a href="mailto:morteza.ansari@webex.com">morteza.ansari@cisco.com</a></td></tr>
    <tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
    <tr><td class="author-text">&nbsp;</td>
        <td class="author-text">Kelly Grizzle</td></tr>
    <tr><td class="author-text">&nbsp;</td>
        <td class="author-text">SailPoint</td></tr>
    <tr><td class="author" align="right">Email:&nbsp;</td>
        <td class="author-text"><a href="mailto:kelly.grizzle@sailpoint.com">kelly.grizzle@sailpoint.com</a></td></tr>
    <tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
    <tr><td class="author-text">&nbsp;</td>
        <td class="author-text">Erik Wahlström</td></tr>
    <tr><td class="author-text">&nbsp;</td>
        <td class="author-text">Technology Nexus</td></tr>
    <tr><td class="author" align="right">Email:&nbsp;</td>
        <td class="author-text"><a href="mailto:erik.wahlstrom@nexussafe.com">erik.wahlstrom@nexussafe.com</a></td></tr>
</table>
</body></html>